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1.  INTRODUCTION 


A  Dialogue  Management  System  (DMS)  is  a  special  system  for 
creating,  modifying,  and  testing  human-computer  interfaces.  In 
general,  DMS  consists  of  three  aspects  —  an  execution 
environment  for  dialogue  and  application  software,  a  set  of  tools 
for  creating  software  and  hiaman- computer  interfaces,  and  a 
methodology  for  creating  software  using  the  tools  and  the 
execution  environment.  This  report  is  a  technical  description  of 
the  DMS  execution  environment,  and  it  includes  the  details  of  the 
FORTRAN  procedures  by  means  of  which  software  is  created  to  run 
under  the  DMS  system.  These  procedures,  in  addition  to  the 
constructs  of  a  standard  programming  language  such  as  PASCAL  or 
FORTRAN,  are  used  to  implement  human-computer  Interfaces  at  an 
Intermediate  implementation  level.  Later,  the  DNS  tools  will 
provide  high-level  techniques  for  producing  such  interfaces 
without  requiring  the  authors  of  those  interfaces  to  be  aware  of 
the  details  at  the  intermediate  level. 

The  system  described  here  is  based  upon  the  belief  of  the 
DMS  group  at  Virginia  Tech  that  there  should  be  logical  and 
physical  separation  between  software  that  implements  the 
dialogues  between  human  and  coiiq;>uter  and  the  software  that 
achieves  the  computational  goals  of  a  computing  system.  The 
former  are  referred  to  as  dialogue  programs,  and  the  latter  are 
called  computational  programs. 


2.  FUMCTIOMAL  DECOMPOSITION  OF  PROGRAMS 


DMS  was  motivated  by  a  desire  to  improve  the  design  and 
management  of  human-computer  interfaces  by  providing  a  special 
environment  for  software  production  activities.  Hartson,  Ehrich, 
and  Roach  [1]  point  out  that  one  of  the  fundamental  reasons  for 
the  existence  of  so  many  poorly  designed  and  inflexible  human- 
computer  interfaces  is  that  current  software  design  methodology 
encourages  the  production  of  program  megaliths  in  which  the 
software  components  are  strongly  coupled  and  interwoven.  In 
particular,  the  failure  to  differentiate  between  software  that 
implements  the  human-computer  interface  and  software  that 
implements  the  computational  tasks  has  led  to  many  of  the 
problems.  One  of  those  problems  is  the  failure  to  recognize  that 
the  design  team  having  the  competence  to  produce  computational 
software  frequently  does  not  have  the  same  competence  in  human 
factors  and  communication.  A  corollary  is  that  many  design  teams 
do  not  fully  grasp  the  difference.  A  second  problem  is  that  the 
software  design  tools  that  exist  for  application  software  design 
are  not  likely  to  be  the  same  tools  that  are  needed  for  the 
design  of  the  human-computer  interface.  Yet  a  third  consequence 
of  monolithic  software  design  is  an  inflexibility  that  may 
require  considerable  redesign  when  relatively  small  details  of 
either  application  or  interface  software  need  to  be  changed. 

Depending  upon  the  nature  of  the  software  task,  there  may  be 
a  very  close  relationship  between  the  design  of  the  human- 


conqputer  interface  and  the  design  of  the  conq^utational  software. 
Thus,  the  dialogue  author  and  the  computational  programmer  may 
need  to  work  jointly  on  significant  portions  of  the  design 
specifications.  We  can  clearly  distinguish  two  extreme  types  of 
software,  called  computation  dominant  and  dialogue  dominant 
software.  In  the  case  of  computation  dominance,  the  control 
logic  is  entirely  contained  in  the  logic  of  the  computational 
component  so  that  whatever  dialogue  logic  exists  is  distinct  and 
easily  decomposed  from  the  logic  of  the  computational  component. 
Dialogue  dominance  is  just  the  opposite.  In  this  case  the 
control  logic  is  entirely  contained  in  the  dialogue,  and  again 
the  computation  and  dialogue  components  are  easily  decomposed. 
Most  text  editors  would  resemble  the  dialogue  dominant  case. 
Host  other  software  is  somewhere  in  between,  and  its  design 
requires  the  cooperation  of  the  dialogue  author  and  the 
programmer  of  the  computational  component.  What  is  important  is 
not  the  classification  of  a  software  task  but  the  recognition  of 
the  distinct  roles  of  the  dialogue  author  and  the  programmer  in 
the  software  production  process.  If  one  is  willing  to 
acknowledge  these  distinct  roles,  then  it  does  not  require  much 
further  argument  to  reach  the  conclusion  that  the  objects 
designed  by  these  authors  ought  also  to  be  locally,  logically 
distinct  despite  the  global  interrelationships  that  bind  them 
together.  It  is  the  function  of  the  DMS  execution  environment  to 
provide  the  mechanism  by  means  of  which  this  logical  separation 
can  be  implemented. 
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There  are  several  ways  to  achieve  separation  of 
computational  modules  from  dialogue  modules.  For  example,  a 
progr£un  might  simply  make  calls  to  procedures  that  contain 
dialogue  or  computational  code  but  not  both  together.  Another 
alternative  is  to  structure  programs  so  that  dialogue  and 
computational  components  are  distinct  despite  their  presence  in 
the  same  code  body.  Yet  another  solution  makes  use  of 
multiprocessing  to  enforce  separation  and  to  make  possible 
dialogue  and  computational  concurrencies  that  would  not  otherwise 
be  possible.  This  last  alternative  is  the  one  that  has  been 
selected. 

One  of  the  most  powerful  concepts  for  implementing  locally 
independent  but  globally  interrelated  software  units  is  the 
process.  A  process  provides  the  environment,  services,  and 
resources  necessary  for  running  a  program,  which,  in  the  Digital 
Equipment  Corporation  (DEC)  tradition,  will  be  called  an  image  to 
distinguish  the  bound  executable  module  from  source  or  object 
code.  A  process  exists  solely  for  the  purpose  of  executing  an 
image,  which  is  both  a  logically  and  physically  distinct  software 
entity,  much  like  that  which  a  dialogue  author  or  programmer 
would  produce.  The  physical  realization  of  the  global  links 
between  dialogue  or  computational  software  modules  is  the 
interprocess  communication  facility,  and  it  is  partly  the  role  of 
IMS  to  provide  well  engineered  interprocess  communication 
constructs  within  the  context  of  the  host  operating  system. 

I 


I 
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The  principal  consequence  of  DMS  methodology  is  that  a  task 
that  might  be  iiq>lemented  as  a  single  program  under  conventional 
software  methodology  will  normally  be  implemented  as  a  set  of 
independent  communicating  programs,  each  of  which  executes  in  a 
separate  process.  Such  a  set  of  communicating  programs  will  be 
referred  to  as  a  program  complex.  There  are  numerous  benefits 
from  this  type  of  program  decomposition.  Module  interactions  are 
minimized,  and  that  facilitates  the  design  of  the  programs  that 
r\in  under  the  various  processes.  Concurrencies  among  modules 
become  a  reality,  and  since  dialogue  and  computational  code  may 
well  require  different  implementation  tools,  more  specialized 
tools  can  be  applied.  The  way  in  which  a  task  is  decomposed 
depends  upon  the  control  structures  within  the  algorithm  that 
carries  out  the  task.  For  example,  dialogue  tasks  are  separated 
from  computation  tasks,  and  the  interrelationships  between  thcun  ^ 
depends  upon  whether  the  overall  task  is  dialogue  or  computation 
dominant.  Thus,  modifications  to  a  software  unit  may  be  made  by 
modifying  any  of  the  programs  of  the  complex  individually  or  by 
altering  the  communication  among  the  programs. 

In  order  to  account  for  the  different  possible  relationships 
among  the  programs  of  a  complex  it  is  necessary  to  distinguish 
special  types  of  programs  called  executors  and  coprograms.  These 
are  distinguished  on  the  basis  of  their  internal  structure,  and 
they  may  Inqplement  either  dialogue  or  conqputation,  depending  upon 
whether  or  not  they  are  permitted  to  communicate  with  a  user. 
Thus  there  may  be  dialogue  programs,  executors,  and  coprograms. 


and  computation  programs,  executors,  and  coprograms.  Executors 
have  a  particularly  important  structure;  they  are  collections  of 
modules  that  do  not  call  one  another  and  have  no  shared  global 
environment.  The  module  interrelationships  are  defined  by  the 
programs  that  invoke  them.  Few  programs  are  organized  as  pure 
executors,  but  they  contain  an  asymptotic  structure  that  is 
importamt  because  of  the  independence  of  the  component  modules. 

Programs  and  executors  are  used  in  situations  where  there  is 
clear  computation  or  dialogue  dominance.  The  dominant  task  i's 
implemented  as  a  program  that  makes  specific  requests  of  the 
executor,  which  achieves  logically  distinct  subtasks  and  returns 
information  to  the  requesting  prograun.  While  specific  examples 
are  shovm  later,  the  idea  is  that  the  executor  is  subordinate  to 
the  requesting  program,  and  it  exists  to  satisfy  the  program's 

PROGRAM 


REQUEST 

SEND 

SEND 


COLLECT 
RECEIVE 
RECEIVE 
END_REQUEST 

Figure  1  -  Program-Executor  Relationship 


EXECUTOR 


SEND 

SEND 
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requests.  The  protocol  that  has  been  implemented  looks  roughly 
as  shown  in  Figure  1.  REQUESTS  and  ACCEPTS,  and  RECEIVES  and 
SENDS  are  complementary.  The  progreun  makes  a  request  of  an 
executor  which  is  acknowledged  when  the  executor  reaches  its 
accept  state.  Then  the  program  sends  data  to  the  executor  and, 
when  it  desires  the  executor's  response,  collects  the  responses 
by  issuing  receives.  The  executor  selects  the  appropriate 
service  (e.g.  dialogue  module)  specified  by  the  request,  issues 
matching  receives  and  sends  to  obtain  and  return  information,  and 
performs  any  necessary  input,  output,  or  computation.  Either 
side  of  the  diagram  in  Figure  1  might  contain  computational  or 


REQUEST  - ►  ACCEPT 

SEND  - ►  RECEIVE 

END_REQUEST 


•  • 

ACCEPT  -  REQUEST 

RECEIVE  -  SEND 

END_REQUEST 


Figure  2  -  Coprogram  Relationship 


dialogue  code. 

One  possible  organization  of  the  coprogram  relationship  is 
illustrated  in  Figure  2.  This  relationship  applies  when  there  is 
no  clear  computation  or  dialogue  dominance.  In  this  case 
information  is  simply  shuttled  back  and  forth  between  the 
coprograms  which  execute  in  a  quasi -synchronous  manner.  Of 
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course,  any  progreun,  coprogram,  or  executor  may  issue  requests  to 
any  number  of  programs.  Each  program  is  identified  in  the 


ACCEPT 

RECEIVE 


REQUEST 

SEND 

SEND 

COLLECT 

RECEIVE 

RECEIVE 

END_REQUEST 


SEND 


Figure  3  -  Third-Party  Request 
request  by  the  image  name. 

One  other  structure  called  a  third-party  request  is 
possible.  This  situation,  shown  in  Figure  3,  occurs  when  an 
executor  inserts  a  request  to  another  executor  in  the  middle  of 
its  service  to  a  program.  Such  a  request  may  be  made  only  after 
the  executor  completes  its  RECEIVE  sequence  and  before  beginning 
its  SEND  sequence.  It  is  the  author's  responsibility  to  avoid 
circular  3rd  party  requests  that  may  lead  to  a  deadlock.  In  the 
same  spirit  it  is  the  authors'  responsibility  to  agree  upon 
request  names,  to  ensure  that  RECEIVES  and  SENDs  are  properly 
paired,  and  to  ensure  that  the  correct  amount  of  data  is 


transferred. 


3.  INTERPROCESS  COMMUNICATION 


DMS  has  been  implemented  using  a  variation  of  the  rendezvous 
concept  [21  in  which  two  processes  must  synchronize  before  an 
interprocess  dialogue  can  be  initiated.  While  there  are  some 
requirements  that  are  better  served  by  asynchronous 
communication,  it  was  felt  that  s3^chronou8  constructs  would  be 
easier  to  implement  and  much  less  confusing  to  nonspecialists  in 
concurrent  programming.  In  this  implementation,  an  image  called 
ENTRY  is  rvin  under  the  user's  login  process.  ENTRY  is  the 
central  executive  of  DMS,  and  all  DMS  processes  are  subprocesses 
of  the  process  running  ENTRY.  Included  in  ENTRY'S 
responibilities  are: 

1)  Conducting  the  default  dialogue  for  initiating 
the  execution  of  a  complex. 

2)  Maintaining  the  image  name,  process 

identification  code,  mailbox  name,  and  status 
for  each  DMS  process. 

3)  Supervising  process  and  mailbox  creation. 

4)  Supervising  mailbox  deallocation  and  process 
shutdown  for  both  normal  and  abnormal 
termination. 

5)  Servicing  queries  about  processes  that  permit 
images  to  locate  one  another  and  establish 
communications . 

Since  this  is  a  ^AX/VMS  implementation,  the  interprocess 
communication  mechanism  is  called  a  mailbox,  which  is  a  portion 
of  non-paged  physical  memory.  Mailboxes  are  treated  as  ordinary 
input/output  devices,  and  requests  are  queued  if  they  cannot  be 
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serviced  immediately.  Each  process  has  one  request  mailbox  whose 
name  is  based  upon  its  process  identification  code,  which  is  a 
unique  number  assigned  by  the  operating  system  to  the  process 
when  it  is  created.  An  image  never  writes  to  its  own  mailbox, 
which  is  treated  as  read  only  by  its  process.  In  each  process 
except  the  one  running  ENTRY,  mailboxes  are  serviced  by  software 
interrupts  called  asynchronous  system  traps  (AST's).  Thus 
mailboxes  are  read  almost  instantaneously  with  one  exception. 
Vfhen  data  (as  opposed  to  control  information)  are  being 
transferred,  since  each  image  has  only  limited  local  buffer 
space,  AST's  are  disabled  in  the  receiving  process  until  the 
received  data  can  be  copied  to  its  final  destination  to  free  the 
receive  buffer. 

Two  processes  are  required  to  synchronize  at  the  beginning 
of  each  interprocess  dialogue.  If  process  A  requests  a  dialogue 
with  process  B,  A  sends  B  a  request  and  hibernates  until  B  gives 
A  its  attention.  Then  A  and  B  can  communicate  freely,  but  with 
two  constraints.  In  order  to  receive  information  from  B,  A  must 
issue  a  collection  request  to  B  at  some  point  before  information 
is  desired  from  B.  This  permits  A  to  initiate  concurrent 
dialogues  with  several  processes  and  then  order  the  processes 
from  which  it  desires  responses.  The  second  constraint  is  that 
if  B  makes  a  third  party  request  to  C,  it  may  only  do  so  when  A 
has  finished  transmitting  data  to  B.  Otherwise  B  would  not  be 
able  to  distinguish  data  received  from  A  from  data  received  from 
C.  With  the  exception  of  the  preceding  caution,  A  and  B  may 
freely  exchange  data  in  either  direction  as  long  as  they  choose. 
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As  an  executor  receives  requests,  they  are  queued  internally 
and  then  serviced  according  to  their  priority.  Once  a  request  is 
serviced,  the  rendezvous  is  in  effect  until  both  processes  decide 
to  end  the  dialogue.  With  such  an  implementation  the 
organization  of  an  executor  is  quite  simqple,  since  it  queues  only 
requests  amd  carries  out  only  one  interprocess  dialogue  at  a 
time. 


To  complete  the  description  of  the  IMS  execution 
environment,  a  brief  account  of  the  communications  that  take 
place  internally  is  given  next.  Suppose  that  image  A  is  a 

computational  program  and  that  image  B  is  a  dialogue  executor. 
When  a  user  runs  ENTRY,  the  user  gives  A's  name  in  the  default 
dialogue,  and  its  process  is  created.  When  A  executes  a  REQUEST, 
A  creates  a  mailbox  and  informs  ENTRY  that  it  has  done  so.  Since 
A  has  never  communicated  with  B  before,  A  asks  ENTRY  for  the  name 
of  B's  mailbox.  ENTRY,  however,  has  no  knowledge  of  B  either,  so 
it  creates  a  process  that  runs  B.  As  soon  as  B  executes  an 

ACCEPT,  B  creates  a  mailbox  and  Informs  ENTRY.  Next,  ENTRY 
checks  whether  any  image  needed  B's  mailbox  name,  and  it 

immediately  sends  the  information  to  A,  whose  process  is 
hibernating.  A  wakes  up  and  now  requests  service  from  B  and 
waits  for  acknowledgement,  which  comes  immediately,  since  B's 

process  is  hibernating.  Then  data  exchanges  follow.  If  A  later 
requests  service  from  B  again,  ENTRY  is  not  queried,  since  A 
remembers  B's  mailbox  name. 
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lliere  ar«  tvo  ways  in  which  procassas  ara  ranovad.  If  tha 
DELETE_PROCESS  aarvica  ia  callad,  ENTRY  broadcaata  a  notica  to 
all  procassas  to  cancal  racorda  of  tha  dalatad  procass,  and  than 
it  dalatas  tha  procass.  If  any  imaga  tarminatas  nomally  or  by 
accident,  ENTRY  laams  of  tha  event  by  receiving  a  massage  in  a 
special  mailbox  called  a  termination  mailbox.  Whan  such  a 
massage  is  received,  ENTRY  deletes  all  processes,  sends  any  error 
massage  to  the  standard  error  device,  and  returns  to  tha  default 
dialogue  so  that  the  user  can  execute  another  conqplex. 
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4.  CONCURRENCY 


Up  to  now  the  merits  of  the  multiprocess  environment  for  IMS 
have  been  argued  on  the  basis  of  the  functional  decomposition  of 
programming  tasks.  However,  there  is  far  more  involved.  There 
is  no  difference  in  the  theory  if  the  individual  processes  were 
separate  hardware  processors.  Ail  of  them  may  fiuiction 
concurrently  with  only  weak  constraints  imposed  in  part  to  make 
the  programmer's  job  easier.  Most  restrictive  is  the  constraint 
that  a  process  issuing  a  REQUEST  will  hibernate  until  that 
request  is  acknowledged.  However,  assuming  that  the  required 
executors  or  co-programs  are  free,  a  program  may  initiate 
multiple  dialogues  that  execute  concurrently  with  one  another  and 
concurrently  with  its  own  code. 

There  exist  several  programming  environments  that  provide 
multiple  processes  and  interprocess  communication  facilities, 
among  them  ADA  ( 2  ] ,  concurrent  PASCAL  [  3  ] ,  and  UNIX  { 4  ] .  These 
differ  from  one  another  in  their  constructs  and  implementation, 
and  since  their  definition  is  standard,  one  does  not  have  the 
freedom  to  adapt  them  to  the  specific  needs  of  dialogue 
management.  One  need  that  has  been  addressed,  for  example,  is 
the  notorious  complexity  of  debugging  asynchronous  concurrent 
programs.  Another  need  is  satisfied  by  the  provision  of  a  built- 
in  mechanism  for  executing  queued  requests  on  the  basis  of  their 
priority.  DMS  is  largely  language  Independent  and  has  an 
architecture  that  can  easily  be  modified  to  meet  the  needs  that 
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arise  as  we  learn  how  to  provide  better  and  better  tools  for 
constructing  human>coiig>uter  interfaces. 


5.  INPUT  AND  OUTPUT 


The  handling  of  I/O  devices  is  one  of  the  most  complicated 
parts  of  implementing  human-computer  dialogues.  In  order  to  be 
able  to  provide  intelligent  input/output  devices  and  software 
capable  of  interacting  with  many  concurrent  users  or 
computational  processes,  each  device  is  controlled  by  a  separate 
program  running  in  a  distinct  DMS  process  and  served  by  the  same 
Interprocess  communication  facility.  For  each  physical  device, 
the  DMS  system  is  supplied  with  a  set  of  high-level  subroutines 
by  means  of  which  input/output  requests  are  made  to  that  device. 
Users  of  DMS  are  not  aware  that  separate  processes  are  created  to 
serve  input/output  requests. 

Every  device  handler  is  accessed  through  two  basic 
subroutines,  INPUT  and  OUTPUT,  in  addition  to  special  subroutines 
designed  to  serve  special  device  features  and  special  device 
software  capabilities.  INPUT  and  OUTPUT  are  used  to  transmit 
ASCII  data  to  and  from  a  device,  and  if  these  subroutines  are 
used,  formatting  must  be  done  by  dialogue  processes.  As  DMS 
evolves,  INPUT  and  OUTPUT  will  be  supplemented  by  hl^er-level 
subroutines  that  support  intelligent  formatting  directly  in  the 
device  process.  Different  physical  device  types  are  controlled 
by  different  device  programs.  However,  if  two  different  device 
types  have  similar  capabilities,  the  same  subroutines  are 
designed  to  support  them.  This  rather  neatly  solves  the  problem 
of  device  dependence  in  input  and  output. 
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On«  iiq>ortant  aspect  of  each  device  process  is  the  queueing 
of  I/O  requests  from  multiple  processes.  There  is  only  a  limited 
priority  system  for  I/O  requests.  All  requests  are  served  on  a 
first-come,  first-served  basis  except  for  output  requests  with 
the  FLASH  mode  specifier.  Such  requests  are  served  first.  In 
order  to  prevent  undesired  shifts  of  focus  in  a  device  dialogue, 
each  communication  with  the  device  may  use  a  KEEP  mode  specifier 
which  blocks  access  to  the  device  to  all  other  processes.  The 
KEEP  is  in  effect  only  for  the  next  communication  unless  the  next 
communication  also  specifies  KEEP.  Even  if  FLASH  is  specified, 
if  another  process  has  reserved  a  device  by  specifying  KEEP,  the 
FLASH  will  be  queued  until  the  device  becomes  free. 
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6.  THE  DMS  USER  PROCEDURES 


The  fifteen  procedures  described  here  pass  requests  by 
character  strings  specified  by  descriptors  and  data  by  reference. 
Considerable  effort  has  been  made  to  simplify  these  services  by 
eliminating  arguments  without  sacrificing  functionality  and 
flexibility. 

6.1  ACCEPT  (reguest_name) 

ACCEPT  is  the  procedure  that  is  executed  in  a  dialogue  or 
computation  executor  or  co-program  in  order  to  obtain  the  name  of 
a  request  for  service  from  another  progriun  in  the  complex. 
Request__name  is  a  character  string  up  to  31  characters  in  length. 
Each  call  to  ACCEPT  in  one  process  is  logically  paired  with  a 
corresponding  REQUEST  in  the  communicating  process.  The  process 
containing  ACCEPT  waits  until  a  service  request  has  been  received 
before  returning.  If  multiple  requests  have  been  queued,  the  one 
with  highest  priority  is  acknowledged. 

6 . 2  COLLECT  ( image^^ncune  ) 

COLLECT  is  called  by  a  program  requesting  service  of  an 
executor  to  trigger  the  return  of  dialogue  or  computational 
results  from  the  executor.  Image_name  is  the  name  of  the 
executor  and  can  be  up  to  63  characters  in  length. 

6.3  CREATE_PROCESS  (image_name) 

This  subroutine  can  be  called  from  any  process  to  explicitly 
create  a  subprocess  of  the  ENTRY  process.  Image  name  is  the  name 
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of  the  image  to  run  under  the  new  process,  and  its  name  must  have 
an  "exe”  filetype.  Image_name  may  be  up  to  63  characters  in 
length.  There  is  an  implicit  call  to  CREATE_PROCESS  whenever  a 
call  to  REQUEST  is  made  specifying  an  image  that  is  not  currently 
running  under  some  process. 

6 . 4  DELETE_FROCESS  ( image_name ) 

This  subroutine  explicitly  deletes  the  subprocess  of  the 
entry  process  that  is  running  the  image  specified  by  image_name. 
Care  must  be  taken  not  to  delete  a  process  that  is  engaged  in  an 
interprocess  dialogue  or  an  I/O  request,  since  other  processes 
participating  in  such  a  dialogue  will  not  be  able  to  proceed. 
lmage_name  may  be  up  to  63  characters  in  length,  and  the  image 
must  have  an  "exe"  filetype. 

6.5  END_REQXra:ST 

This  should  always  be  used  as  the  last  statement  of  a 
dialogue  request.  In  other  words,  each  call  to  REQUEST  should 
eventually  be  followed  by  a  call  to  EMD_REQUEST. 

6.6  INPUT  (device, string, nbytes, mode) 

INPUT  requests  input  data  from  'device',  which  is  specified 
by  a  2-character  string  such  as  'tt'  for  the  user's  login 
terminal.  Nbytes  is  a  4-byte  integer  variable  in  the  range  0  to 
512  that  specifies  the  buffer  size,  and  it  is  set  to  the  number 
of  bytes  returned,  excluding  line  terminator,  if  any.  Mode  is  a 
character  string  that  determines  how  the  input  is  to  be  done.  A 
mode  specifier  can  appear  anywhere  in  the  mode  string,  and  it  can 
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have  upper  or  lower  case.  However,  mode  cannot  be  a  zero- length 
string.  Valid  mode  specifiers  are: 


ECHO 

KEEP 

EDIT 


PURGE 

CR 

LF 

RESTORE 

BELL 


Echo  the  input  characters 

Retain  device  control  after  transmission 

Edit  input  as  follows: 

CR  and  LF  line  terminators 
(MAK)  cancel  line 
CR  (DC2)  refresh  input  line 
DEL  character  delete 
Clear  the  typecdiead  buffer  before  input 
Carriage  return  after  input 
Line  feed  after  input 

After  input,  erase  line  and  restore  cursor 
position 

Ring  the  bell  before  accepting  input 


Example : 


call  INPUT  ( 'tt’ , string, nbytes, 'echo+keep' ) 


6.7  METER  ( id, comment, pi ,p2,p3 , p4, p5 ) 

A  call  to  METER  causes  a  record  to  be  written  to  the 
metering  file  specified  by  the  OPEN_METER  subroutine.  id  and  pi 
-  p5  are  optional  2-byte  integers,  and  comment  is  a  character 
string  of  1  to  35  characters.  Each  record  has  the  following 
format : 


2 

cols 

id 

i2 

11 

cols 

elapsed  seconds 

fll.2 

2 

cols 

sp 

35 

cols 

comments 

5 

cols 

pi 

i5 

6 

cols 

p2 

i6 

6 

cols 

P3 

i6 

6 

cols 

p4 

i6 

6 

cols 

p5 

i6 

1 

col 

NULL 
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6.8  OPEN_METER  (£ile_name) 

This  subroutine  prepares  a  file  to  accept  80-character 
metering  records  produced  by  calls  to  METER.  The  metering  file 
must  be  created  prior  to  a  call  to  OPEN_METER.  A  record  is 
simply  appended  to  this  file  each  time  METER  is  called. 

6.9  OUTPUT  (device, string, nbytes/mode) 

OUTPUT  sends  data  to  'device',  which  is  specified  by  a 
2-character  string  such  as  'tt'  for  the  user's  login  terminal. 
Mbytes  is  a  4-byte  integer  in  the  range  0  to  512  that  specifies 
the  number  of  bytes  to  be  transmitted.  Mode  is  a  character 
string  that  describes  how  the  output  operation  is  to  be 
performed.  A  mode  specifier  can  appear  anywhere  in  the  mode 
string,  and  it  can  have  upper  or  lower  case.  However,  it  cannot 
be  a  zero- length  string. 

KEEP  -  Retain  device  control  after  transmission 
CR  -  Carriage  return  after  transmission 

LF  -  Line  feed  ^fter  transmission 

FLASH  -  Send  a  high  priority  message 

Example : 

Call  OUTPUT  ('tt' , string, 100, 'crlf  and  flash') 

6.10  RECEIVE  (data_reference,nbytes) 

RECEIVE  implements  the  transfer  of  data  from  another  process 
into  the  process  from  which  it  is  called,  and  the  amount  of  data 
transmitted  is  determined  by  the  sending  process.  Data_reference 
is  the  address  of  a  contiguous  byte  array  that  is  to  receive  the 
transmitted  data,  and  nbytes  is  a  4-byte  integer  that  returns  the 
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nvunber  of  bytes  transmitted.  Each  call  to  RECEIVE  in  one  process 
is  logically  paired  with  a  corresponding  SEND  in  the 
communicating  process.  RECEIVE  waits  until  data  have  been 
received  before  returning. 

6.11  REQUEST  ( image_name, request_name, priority) 

REQUEST  is  called  by  a  program  that  wishes  to  invoke 
dialogue  or  computation  by  an  executor.  Image  nsune  is  the  name 
of  the  image  from  which  services  are  requested.  It  must  have  an 
"exe”  filetype  and  may  be  up  to  63  characters  in  length. 
Request_name  is  a  character  string  that  names  the  request  to  be 
serviced  by  the  executor,  and  it  may  be  up  to  31  characters  in 
length.  Each  call  to  REQUEST  in  one  process  is  logically  paired 
with  a  corresponding  ACCEPT  in  the  communicating  process. 
REQUEST  will  not  return  until  the  named  image  is  running,  its 
mailbox  has  been  established,  and  it  has  acknowledged  the 
rec[uest.  If  the  named  image  is  not  running  under  any  process,  an 
implicit  call  to  CREATE_PROCESS  is  made.  Priority  is  a  4-byte 
integer  that  is  used  by  ACCEPT  to  determine  which  request  among 
those  pending  should  be  served  next.  Requests  with  larger 
priority  values  are  served  first. 

6.12  SEND  (data_reference,nbytes) 

SEND  transmits  "nbytes"  bytes  of  contiguous  data  from  a  data 
structure  whose  address  is  given  by  data_reference,  where  nbytes 
is  a  4-byte  integer.  Each  call  to  SEND  in  one  process  is 
logically  paired  with  a  RECEIVE  in  the  communicating  process. 
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SEND  returns  immediately  if  it  is  called  after  a  REQUEST.  When 
called  after  an  ACCEPT,  SEND  returns  immediately  if  the  sequence 
of  SENDS  has  been  enabled  by  another  process  by  a  call  to 
COLLECT.  SEND  should  not  be  issued  by  a  requesting  process 
unless  RECEIVE  is  the  next  subroutine  to  be  executed  by  the 
accepting  process.  Otherwise  the  accepting  process  will  be 
deadlocked. 

6.13  STATUS_REPORT 

Any  process  running  under  DMS  can  request  that  the  status  of 
all  subprocesses  with  mailboxes  be  transmitted  to  the  user's 
login  terminal.  The  status  report  specifies  which  of  the  DMS 
services  ACCEPT,  COLLECT,  END_REQUEST,  RECEIVE,  REQUEST,  or  SEND 
is  currently  being  executed  or  was  most  recently  executed.  Where 
applicable,  the  name  of  the  communicating  image  and  the  requested 
service  is  also  returned.  This  subroutine  is  used  for  debugging 
purposes  in  determining  the  execution  state  of  DMS  subprocesses, 
and  the  same  status  report  can  be  obtained  from  DMS 
interactively. 

6.14  TERMINATE  (mode) 

Terminate  calls  for  termination  of  the  program  complex 
currently  running  under  DMS  or  causes  the  termination  of  DMS 
itself.  Mode  is  a  character  string  that  determines  the  effect  of 
TERMINATE  -  'complex'  if  the  current  complex  is  to  be  terminated 
and  'dms'  if  DMS  itself  is  to  be  terminated.  Control  of 
execution  never  returns  from  TERMINATE.  Terminate  can  also  be 
executed  interactively  through  the  DMS  system. 
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6.15  TRACE  (onoff) 

Any  process  running  under  DMS  can  rec[uest  an  execution  trace 
of  the  DMS  services  ACCEPT,  COLLECT,  END_REQUEST,  RECEIVE, 
REQUEST,  and  SEND.  When  TRACE  is  called,  the  trace  begins  for 
all  processes  that  have  a  mailbox  at  the  time  the  request  is 
issued.  Onoff  is  a  character  string  that  turns  trace  mode  on  if 
'ON'  and  off  if  'OFF'.  A  trace  is  a  time- sequential  transcript 
that  shows  the  entry  and  exit  from  each  of  the  above  six  IMS 
sxibroutines  and  a  record  of  each  interprocess  communication  sent 
to  a  process  mailbox.  This  subroutine  is  used  for  debugging 
purposes  in  determining  the  execution  state  of  DMS  subprocesses. 
Trace  can  also  be  turned  on  or  off  from  DMS  interactively,  and 
all  trace  output  is  sent  to  the  file,  TRACE. DMS. 
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7.  USING  DNS 


This  section  presents  short  examples  of  communicating 
progr2uns  written  in  FORTRAN  and  PASCAL  that  demonstrate  how  the 
DNS  multiprocess  environment  is  to  be  used.  Also,  this  section 
contains  specific  notes  about  the  VAX/VMS  environment  which  hosts 
the  DNS  system. 


7.1  A  FORTRAN  Example 

c  This  progr2un  gets  a  number  and  doubles  it. 

c  Let's  assume  that  this  program  is  called  FDEHO. 

c  According  to  DNS  methodology,  this  program  may  not 
c  communicate  with  a  user. 

c  This  program  executes  in  a  sxibprocess  of  the  user's 

c  login  process  concurrently  with  FEXEC. 

call  REQUEST  ( ' f exec  * , ' get_number ' , 0 ) 
call  COLLECT  ( ' fexec' ) 
call  RECEIVE  (n,nbyte8) 
call  END_REQUEST 


m=2*n 


call  REQUEST  ( ' fexec ' , ' print_number s ' , 0) 
call  SEND  (n,4) 
call  SEND  (m,4) 
call  END_REQUEST 

call  REQUEST  ( ' fexec ' , ' 8hutdo%m' , 0 ) 
call  END_REQUEST 


c  This  is  s  dialogue  executor  that  serves  the  requests 

c  from  FDENO  and  does  all  its  input  and  output, 

c  Let's  assume  that  this  executor  is  called  FEXEC. 
c  This  program  executes  in  a  subprocess  of  the  user's 
c  login  process  concurrently  with  FDEMO. 

CHARACTER* 31  request_name 

10  call  ACCEPT  ( reque8t_name) 

if  (reque8t_name.eg. 'get_nvimber' )  then 
type  *,  'Enter  an  integer* 
read  * ,  n 
call  SEND  (n,4) 
end  if 

if  (regue8t_name.eg. 'print_nvimber8' )  then 
call  RECEIVE  (i^nbytes) 
call  RECEIVE  (j,nbytes) 
type  '2',i,'  equals ',j 
end  if 

i f  ( reguest^name . eq . ' shutdown ' )  cal 1  exit 

go  to  10 

end 


Looking  first  at  FDEMO,  the  first  request  is  for  an  input 
value  to  be  used  in  a  simple  computation.  Since  FDENO  has 
nothing  to  send  the  dialogue  executor,  it  calls  COLLECT  and 
obtains  the  value  from  FEXEC.  Then,  a  request  is  made  for  FEXEC 
to  print  the  input  and  output  values.  Since  they  are  not 
necessarily  contiguous  in  storage,  two  calls  are  made  to  SEND, 
each  having  4  bytes  since  the  default  FORTRAN  integer  data  type 
is  INTECER*4.  Finally,  the  program  complex  is  terminated  by  the 
REQUEST  for  the  shutdown  service.  Since  the  requests  are 
executed  on  a  first-come,  first-served  basis,  the  shutdown 
request  which  causes  all  programs  in  the  coa^lex  to  terminate 
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will  not  be  executed  by  FEXEC  \mtil  it  has  finished  printing  out 
the  results  for  the  user. 


FEXEC  begins  with  an  ACCEPT  statement,  and  once  a 
request_name  is  obtained,  the  corresponding  request  is  executed. 
The  only  unusual  service  is  shutdown,  which  causes  a  program 
exit,  which,  in  turn,  causes  the  entry  process  to  delete  all 
processes  in  the  complex  and  return  to  the  default  dialogue. 

The  following  exasqsles  are  identical  to  the  previous  ones 
except  that  both  the  application  program  and  the  dialogue 
executor  have  been  coded  in  VAX  PASCAL.  Otherwise,  the  previous 
discussion  applies  also  to  these  programs. 


7.2  A  Wj^X  PASCAL  Example 
program  pdemo; 

{  This  program  gets  a  number  and  doubles  it. 

According  to  DNS  methodology,  this  program  may  not 
communicate  with  a  user. 

This  program  executes  in  a  subprocess  of  the  user's 
login  process  concurrently  with  PEXEC.} 

type 

executor_name_type  =  packed  array  [1..5]  of  char; 
request_name_type  =  packed  array  [1..13j  of  char; 

var 

m, n, priority, length, nbytes:  integer; 

procedure  REQUEST  (%stdescr  u:  executor_name_type; 

%stde  sc  r  v :  r eque s t_name_type ; 
var  w:  integer);  extern; 

procedure  COLLECT  (%stdescr  u:  executor_name_type) ;  extern 
procedure  RECEIVE  (var  u:  integer; 

var  V:  integer);  extern; 
procedure  EMD_REQUEST;  extern; 

procedure  SEND  (var  u:  integer;  var  v:  integer);  extern; 

begin 
length: s4; 
priority :=0; 

REQUEST  ( ' pexec ' , ' get_number  ' , priority) ; 

COLLECT  ( ' pexec ' ) ; 

RECEIVE  (n,nbytes); 

END_REQUEST; 

m:=2*n; 

REQUEST  ( ' pexec ' , ' print_numbers ’ , priority) ; 

SEND  ( n ,  length  )•; 

SEND  (m, length); 

END_REQUEST; 

REQUEST  ( 'pexec* , ' shutdown  ' , priority) ; 

END_REQUEST 

end. 
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program  paxec  ( input, output) ; 

{  This  is  a  dialogue  executor  that  serves  the  requests 
from  PDEMO  and  does  all  its  input  and  output. 

This  program  executes  in  a  siibprocess  of  the  user's 
login  process  concurrently  with  PDEMO.) 

type 

request_name_type  =  packed_array  [1..13]  of  char; 
var 

reguest_name :  reguest_name_type; 
i, j ,n, length, nbytes:  integer; 

procedure  ACCEPT  (%stdescr  u:  request_name_type) ;  extern 
procedure  SEND  (var  u:  integer, var  v:  integer);  extern; 
procedure  RECEI\^  (var  u:  integer; 

var  V:  integer);  extern; 
procedure  SYS$EXIT;  extern; 

begin 

length=4; 

repeat 

ACCEPT  ( reguest_name ) ; 
case  reguest_name  [1]  of 

•g’: 

begin 

writeln  ('Enter  an  integer'); 
readln  (n); 

SEND  (n, length) 
end; 


begin 

RECEIVE  (i, nbytes); 

RECEIVE  (j, nbytes); 
writeln  ('2',i,'  equals ',j) 
end; 

's':  SYS$EXIT 
end 

until  false 
end. 
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One  more  example  is  given  that  demonstrates  the  use  of  the 
DNS  I/O  system.  In  this  example,  a  line  of  up  to  25  characters 
is  typed  with  echo  to  the  user.  When  carriage  return  is  struck, 
the  line  is  repeated  on  the  user's  terminal.  If  the  first 
character  is  an  uppercase  'S',  OMS  is  terminated. 


7.3  Another  FORTRAN  Example 


c  This  program  parrots  the  input  typed  on  the  user's 

c  terminal.  If  25  or  more  characters  are  typed  or  if 

c  CR  is  struck,  the  line  typed  is  retyped. 

CHARACTER*25  buffer 

10  nbyte8-25 

call  INPUT  ( 'tt' , buffer, nbytes, 'EDIT  +  ECHO  +  CRLF' ) 
call  OUTPUT  ( 'tt' , buffer, nbytes, 'CRLF' ) 

if  (buffer(l).eq. 'S' )  call  TERMINATE  ('dms') 

go  to  10 

end 
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Concurrent  Proqramg 


7.4  Debugging 

STATUS_REPORT  and  TRACE  will  provide  static  and  dynamic 
information  about  interprocess  communication  in  DMS.  The  TRACE 
result  is  a  readable  transcript  that  shows  a  time- sequential 
history  of  information  transmission  and  subroutine  execution. 
Sometimes  the  order  of  items  in  the  transcript  may  seem  peculiar. 
This  is  because  in  a  timesharing  system  only  one  process  can 
actually  execute  at  a  time  while  others  await  their  turn.  The 
TRACE  result  is  sent  to  the  file,  TRACE. IMS,  where  it  is  saved 
for  subsequent  analysis. 


7.5  Running  DMS  on  the  VAX 

Before  naming  DMS  on  VAXl,  all  the  programs  that  are  to  run 
under  its  control  need  to  be  linked  to  the  DMS  library.  The  two 
most  common  ways  of  doing  the  link  would  be  either  to  specify  the 
DMS  library  explicitly  in  the  link  command  or  to  define  a  link 
library  in  the  LOGIN.COM  file.  The  two  alternatives  are 

(1)  LINK  PROGRAM, I EHRICH. DNSS IDMS/LIB 

(2)  DEFINE  LNK$LIBRARY  [ EHRICH. DNSS ] DMS 

The  name  of  every  program  running  under  DNS  is  mapped 
through  logical-name  translation.  If  the  DNS  user  wishes  to  run 
two  different  programs  in  a  process  without  recoding  the  program 
references  in  the  complex,  logical  names  can  be  used.  If  no 
logical  name  exists,  the  given  name  is  used.  Suppose,  for 
example,  that  a  coo^lex  references  a  program  called  JUDY.  If  the 


U8«r  wishes  to  substitute  GEORGE  for  JUDY,  it  is  only  necessary 
to  type 


ASSIGN  george  judy 

before  executing  DMS.  Of  course,  in  this  case  the  file  named 
GEORGE  could  have  been  renamed  JUDY,  but  that  is  not  always 
possible  if  GEORGE  is  in  another  directory. 

For  each  I/O  device  xx  referenced  in  a  program  conqplex,  two 
things  are  required  for  execution  of  that  conqplex: 

1)  A  logical  name  xx  that  translates  to  the  physical  I/O 

device  (like  _TTA4: ) 

2)  A  driver  (or  a  logical  name  that  translates  to  a  driver) 

whose  name  is  XXDRIVER. 

The  only  exception  is  XT,  which  by  default  translates  to  the 
user's  login  terminal. 

Logical  names  can  also  be  used  to  run  multiple  devices  with 
one  driver  program.  Suppose  three  identical  devices  are  required 
whose  drivers  are  GGDRIVER,  and  suppose  that  in  the  program 
complex,  the  devices  are  referenced  by  Gl,  G2,  and  G3.  The 
translations  for  GIDRIVER,  G2DRIVER,  and  G3DRIVER  are  all  set  to 
be  G(n>RIVER,  and  the  translations  for  Gl,  G2,  and  G3  are  set  as 
usual  to  be  the  physical  terminal  line  names. 

To  run  DNS,  type 


R  [EHRICH. DNSS] ENTRY 
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ENTRY  is  the  name  of  the  central  program  that  supervises  the 
execution  of  all  the  images  in  its  subprocesses.  When  ENTRY 
runs,  the  prompt 

Welcome  to  OMS:  enter  the  image  name 

will  be  typed,  and  all  the  user  need  do  is  specify  the  name  of 
the  image  that  starts  the  execution  of  the  program  complex.  In 
the  case  of  the  FDEMO  and  FEXEC  programs  given  previously,  FDEHO 
is  all  that  need  be  typed.  Typing  FEXEC  will  not  work  since 
FEXEC  contains  no  reference  to  FDEMO  that  would  cause  it  to  begin 
execution.  Remember  also  that  if  any  program  in  the  complex 
terminates  in  any  way  except  by  a  call  to  DELETE_PROCESS,  ENTRY 
will  terminate  the  entire  coiig>lex  and  return  to  the  default 
dialogue. 


7.6  Interacting  with  DMS 

When  a  DMS  user  types  ^C,  ENTRY  types  the  prompt  DMS>,  which 
is  a  request  to  the  user  to  issue  a  command  to  the  DMS  system 
itself.  While  in  IX(S  command  mode,  all  processes  are  active,  but 
DNS  output  (ie,  output  sent  through  a  DMS  device  process)  to  the 
login  terminal  is  blocked.  When  X  is  typed,  current  output- 
requests  are  terminated,  and  any  pending  read- request  will  be 
reissued.  If  any  FORTRAN  or  PASCAL  read- requests  to  the  login 
terminal  are  active,  an  additional  CR  will  be  required  to  get  the 
DMS>  prompt.  Any  such  read  request  will  subseqpiently  be 


reissued. 


The  DMS  conmands  are: 


Quit,  STOp,  Exit,  TErminate 

TErminate  Complex 

TRace  ON 

TRace  OFf 

STAtus  report 

<CR> 


DMs  to  leave  IMS 

to  reinitiate  DMS 
to  turn  trace  on 
to  turn  trace  off 
to  get  a  status  report 
to  leave  interactive  mode 


DMS  requires  certain  privileges  and  quotas.  These  include 


PRCLM 

BYTLM 

TNPMBX 

GRPMAN 

GROUP 


nproc 

2500  *  (nproc  +  1) 


where  nproc  is  the  maximum  number  of  concurrent  programs  in  the 
complex  to  be  run. 

Users  should  use  the  hibernate  system  sexrvice  (sys$hiber) 
with  caution  since  any  communications  to  the  process  mailbox  such 
as  a  service  request  will  cause  a  wakeup  to  be  Issued  by  the  AST 
that  services  the  mailbox.  For  applications  requiring  time 
delays,  procedures  such  as  DELAY  (<100  seconds)  or  LOMG_DELAY  (>1 
second)  should  be  used  since  they  use  the  sys$setimer  service. 
These  are  also  found  in  the  DNS  library. 
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